Dynomotion

Group: DynoMotion Message: 11890 From: Hardy Family Date: 7/13/2015
Subject: Estop button mutually exclusive with user buttons
We have reprogrammed the Estop button in Kmotion-CNC to work slightly differently than standard (e.g. we don't want to kill certain threads).  Unfortunately, it cannot be used during certain long-running activities that are invoked from user buttons, such as homing the machine.  This is because the GUI thread is looping waiting for the user button program to complete, and thus the GUI loop doesn't get to process button events.  I don't think this is specific to our mods.

If the Estop button does not always work, then we consider it better not to have it at all, however we would like to have it since a lot of our Mach3 customers, that we are migrating, are used to it.  (My own opinion is that Estop should always be a hardware button and people should just get used to it, but I'm not world dictator so we have to live with it.)

So the question is what would be the best approach to modifying K-CNC so that the Estop button does not mutex with user buttons?

My impulse is to move the code which waits for user program completion into the interpreter thread.  If the interpreter is doing something, then it generally works better with the GUI.  Of course, this is considerable work, so I was wondering if there is an easier/better way.

If execute+wait user buttons were handled more like MDI commands, I think that would be satisfactory for us.  We don't need or want these user programs to execute at the same time as g-code.

Regards,
SJH
Group: DynoMotion Message: 11892 From: Tom Kerekes Date: 7/13/2015
Subject: Re: Estop button mutually exclusive with user buttons
Hi SJH,

I agree but I'm not sure of the best solution at this point.  I think this is also related to the issue where User Buttons run KFLOP Programs that attempt to do GUI things like message boxes.  Executing the User Buttons from another Thread would solve that problem as well.

It isn't clear to me why you would specify the "Wait" option if you are just going to wait in another Thread and then do nothing afterward.  Why not just not specify "Wait" as the code runs in a Separate KFLOP Thread anyway.  I suppose you expect the Cycle-Start and Jog Buttons, etc. to be disabled while the User Button Executes?

Regards
TK

Group: DynoMotion Message: 11893 From: Hardy Family Date: 7/13/2015
Subject: Re: Estop button mutually exclusive with user buttons
Not quite sure I follow what you are saying in the 2nd paragraph.  What I mean is that the user button is set to execute+wait.  This is used for homing since nothing else should run until homing is complete (except obviously I want the estop to work).  I did try it with just "execute", but it had a lot of undesirable effects.

Regards,
SJH


On Mon, Jul 13, 2015 at 3:46 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

I agree but I'm not sure of the best solution at this point.  I think this is also related to the issue where User Buttons run KFLOP Programs that attempt to do GUI things like message boxes.  Executing the User Buttons from another Thread would solve that problem as well.

It isn't clear to me why you would specify the "Wait" option if you are just going to wait in another Thread and then do nothing afterward.  Why not just not specify "Wait" as the code runs in a Separate KFLOP Thread anyway.  I suppose you expect the Cycle-Start and Jog Buttons, etc. to be disabled while the User Button Executes?

Regards
TK

Group: DynoMotion Message: 11894 From: Tom Kerekes Date: 7/13/2015
Subject: Re: Estop button mutually exclusive with user buttons
Hi SJH,

Yes I understood the User button is set to "Exec/Wait".  But I was wondering why?   What were the undesirable effects of just "Execute" other than preventing something like Jog or Cycle Start while still Homing.

Regards
TK

Group: DynoMotion Message: 11895 From: Hardy Family Date: 7/13/2015
Subject: Re: Estop button mutually exclusive with user buttons

Well that was basically it.  We don't want the operator doing something silly like that.

Unless there is something to prevent coordinated motion from executing while we are in the process of executing move() etc., then it seems best to just force the PC to wait.

Regards,
Sjh

On Jul 13, 2015 4:14 PM, "Tom Kerekes tk@... [DynoMotion]" <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

Yes I understood the User button is set to "Exec/Wait".  But I was wondering why?   What were the undesirable effects of just "Execute" other than preventing something like Jog or Cycle Start while still Homing.

Regards
TK